The wide availability of storage devices including transient storage devices (“TSDs”) such as flash drives, personal media players, digital cameras, portable external hard disk drives, mobile phones, and the like have provided both home and corporate users with a convenient way to copy data and transport files. TSDs can typically be coupled or mounted to host PCs (personal computers) using communication protocols and interfaces such as USB (Universal Serial Bus). These TSD devices serve much of the same functionality as older mass storage media such as floppy and optical disks but with vastly increased storage capacity with improved reliability at very low cost. Indeed, as TSD capacity continues to increase, the devices can function as containers not only for data, but for applications, or even complete virtual desktops in some cases. TSDs are also being deployed with multiple logical unit numbers (“LUNs”) per physical device where each logical unit behaves like a totally separate device in order to provide even greater functionality and flexibility for users.
Although TSDs provide great convenience and functionality, they can also pose a significant security vulnerability that can make data vulnerable to loss or theft. Not only is it easy to lose a small flash drive on which valuable data is stored, for example, but an unauthorized person can easily connect a USB disk drive or other TSD to an unattended host PC (personal computer) and copy large amounts of sensitive data and/or personal information in a relatively short period of time. In addition, TSDs can have the potential to transport viruses or other malicious software which can then infect the host.
One solution to improve the security of TSDs is provided by IEEE (Institute of Electrical and Electronic Engineers) 1667 “Standard Protocol for Authentication in Host Attachments of Transient Storage Devices.” IEEE 1667 provides a standardized methodology for authenticating TSDs when they are mounted to a host PC. By implementing authentication as specified by the standard, it becomes possible to enhance security and substantially reduce the vulnerability presented by TSDs across a variety of different computing platform and device types. For example, an IT (information technology) administrator in a business enterprise can create an approved set of TSDs that may be authenticated and used by the PCs on the corporate network (“corpnet”) while preventing the use of unapproved rogue devices to thereby keep the enterprise secure. And both home and corporate users can benefit by using IEEE 1667-compliant TSDs to restrict the hosts on which the TSDs will work to reduce the potential for sensitive or personal data becoming compromised if the TSD is lost or stolen.
The IEEE 1667 standard is designed to be extensible and may support a variety of functionalities on a TSD through an architecture that can expose multiple functional units termed “silos.” A silo is a uniquely addressable receiver of commands and one or more silos can exist in a storage area called an “addressable command target” (“ACT”) on a device. ACTs and LUNs have a one-to-one relationship so there is one ACT per LUN. Several specialized silos are used in IEEE 1667 including an authentication silo that provides the functions required for bidirectional authentication and administration of the authentication certificates on the TSD. A probe silo lets the host application query the ACT for its functionality. The IEEE 1667 standard allows up to 254 additional silos in each ACT that can support a variety of non-IEEE 1667 functionalities (for a total of 256 silos) and multiple ACTs/LUNs can be supported on a single TSD.
While TSDs and hosts that implement IEEE 1667 can provide satisfactory results in many applications, the standard does not provide for changes to be made to silo configuration or availability after a TSD is released by its manufacturer to customers. That is, control over the configuration of the TSD is in the hands of the manufacturer and customers have no current ability to make configuration changes when a TSD is deployed in the field at runtime.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.